In a distributed application system, such as those provided by the Tuxedo system developed by BEA Systems, Inc., San Jose, Calif., most of the distributed applications use tightly coupled messages to communicate. Adding or modifying message-related application features almost always requires changing the message format, which has an impact on the rest of the software code that is exposed to the message. The change in message compatibility is an important issue in a multi-release environment.
BEA Tuxedo is just one example of such a messaging system. Earlier versions of the product have a fixed message format to support all of the existing features at the time. The message format is exposed to almost the entire Tuxedo code base. In the past small changes to the message format were made by using a few reserved fields in the message. Major additions to the messaging format were simply not allowed. One resultant problem with this approach is that a single fixed size message format makes use of the system resources and the network bandwidth in a less than efficient way.
The future growth of application server products such as Tuxedo requires an improved messaging system that is flexible enough to facilitate adding major new features with little or no impact to the existing code base. The messaging system should be efficient enough to reduce the message footprint for any features depending on it, without rewriting the code, and to be flexible enough to allow multi-release deployment without patching the older releases. Particularly, a solution to the problem as it affects Tuxedo requires a new message header in order to carry a longer Tuxedo service name and to reduce overhead both on the queues, and over the network. In addition, future projects related to application servers including Tuxedo, require a more flexible format than the existing message header so that different types of data can be carried as part of the header without implying any dependency between the different types of data in order to access, manage or identify each data type. Finally, overall throughput is an important design criteria that should be balanced against the functionality of the messaging system.